Real-time Environmental Monitoring

This topic has 11 replies, 5 voices, and was last updated 9 years, 10 months ago by Ally.

Viewing 12 posts - 1 through 12 (of 12 total)

Author

Posts
December 6, 2014 at 8:19 pm #656
uRADMonitor
Keymaster
Replicating the HTTP Get parameters, one can inject (invalid) data into the system, in order to cripple the network and invalidate measurements.

Current firmware uses an additional CRC , that is harder to replicate by just sniffing the traffic.

Additional solutions are needed to protect data integrity.
- This topic was modified 9 years, 10 months ago by uRADMonitor.
December 7, 2014 at 12:09 am #668

Jeff Cooper
Moderator

Since you know what interval legitimate devices report at, could an algorithm be made to detect messeges that deviate from this?

What about pki? That could be used for non-repudiation on the device’s messages. It may be hard to implement/enforce on diy units though.

December 7, 2014 at 10:40 am #676

uRADMonitor
Keymaster

Delay check might help at least to exclude packets coming too early, so we could have this among other mechanisms.

PKI would be excellent, but probably impossible for the reasons you’ve mentioned, but also because it requires a relatively complex code, and the available memory is low.

We also need to think of a solution as close to plug-and-play as possible. If it’s too hard to implement on DIY units, it will not work.

December 7, 2014 at 1:08 pm #681

vinz
Member

Hello Radu, hello Jeff,
I’m not a friend of total encryption, because it may leed to relying on it.

Much more easy than spoofing data will be takeing sensors down (server side, client side, routing, …).
To prevent this, in first step there might be a flashing “offline” LED on the device or the eMail alert you think about …

But even thou you can make the device believe it’s online.
At the moment my “urad” sends all data to my own server, where I can do those tests.

In next step you could show a current average-value on devices display. Anyone will wonde about the difference online/offline if there is spoofing. In total this might be more reliable than encryption.

But maybe there should be a, lets say .. saltet hash, to prevent easy spoofing.
When registering a new device, you get a divice-id and a shared secret. This secret has to be used to calculate the crc. So not every teenager can send fake date.

Vinz

December 7, 2014 at 1:29 pm #682
vinz
Member
because the topic is “invalid data injection”, I’d like to add this:

In my opinion, every sensor (urad or diy) should have (in first thought) two states:
1) works fine
2) incidence
nothing more

Where “incidence” for example could be:
- Value out of fixed range per device (also lower than minimum is detected!).
- Value out of floating (narrow) range, calculated on historical data.
  Also lower than minimum is detected!
  For example: Value out of 4 times the standard deviation of last year except last 3 days.
- Standard deviation itself (for example last hour) out of fixed limit.
  Meaning devices values are unreliable.
- Device offline.
- Device changed IP-Address in other intervals than regular.
  Standard deviation on the “same-IP-timespan”. ?? 🙂
- Device sent wrong packets within last 3 month.
Please extend this.

The idea of this list is, to detect problems with one sensor without relying on the packets the sensor sent.

Vinz
December 9, 2014 at 6:01 pm #784

Hexide
Participant

Best be if each device had unique key stored in them and it would be attached to device id. Key would be used to hash all data before its sent to server, hash is attached to request.

Server gets request, looks up device by its id and grabs its key.
Validates request data ( does same hashing procedure as device ), if everything matches up – request is probably genuine.
Upsides are that:
1. devices could be pretty easily blacklisted using this method
2. it would be hard to fake some other device

Downsides are that each device would need to have unique binary image on it.

December 9, 2014 at 6:08 pm #788

Hexide
Participant

I had similar project going where program executable had to had unique key in it before all users downloaded.
My approach to this was to take and compile 4 different excecutables with different known keys in them, then using hexedit find differences between those files. Knowing where each difference was I was able to write relatively small script ( in php ) which used single compiled file and replaced key inside of it before it was served to user.

Maybe similar strategy could be used here.
To generate binaries with unique keys, record those keys to database.

Then it would be in human hands to get bin images inside controllers.

December 9, 2014 at 6:14 pm #792

uRADMonitor
Keymaster

Indeed patching would automate the production of unique firmware binaries, without compiling the source code every time.

But there is also the approach presented here: https://www.uradmonitor.com/topic/automated-device-ids/

The eeprom can also be written without changing the firmware using a separate script, after main firmware is written.

December 9, 2014 at 6:21 pm #793
Hexide
Participant
Can device communicate over HTTPS and have built in certificate validation?

Edit: Seems like that would be too much for micro-controller 😛
- This reply was modified 9 years, 10 months ago by Hexide.
December 9, 2014 at 6:27 pm #796

uRADMonitor
Keymaster

Hello Vinz,

I think you have covered pretty much everything to secure the problem and even beyond that to detect if a device is behaving suspicious.

Also @Jeff ‘s suggestion on checking upload interval is important in limiting invalid data.

Unless anyone has anything else to add, I will propose this as solution, and standardise it in a specs document written for the next firmware release.

December 9, 2014 at 7:22 pm #809
vinz
Member
Hello Hexide,
You’re right; I also proposed this “shared secret” used for hashing (see link automated-device-ids).

so I missed
- Devices upload interval is unusual
- Devices timestamp-value is dubious
Does someone have other (maybe mathematical) ideas, to detect suspicious data?

By the way
you also can LIMIT the number of queries in MySQL.

Maybe one MySQL-user per device is too much but user-groups for special urad und DIY-devices may be good. (See: http://dev.mysql.com/doc/refman/5.0/en/user-resources.html).

So one group can’t totally overload the server, and others can still store data.

Example: You could now use one new user for online requests (SELECT) only.
If you limit this user, the database will always be able to store new data.
Vinz
December 10, 2014 at 1:06 am #822

Ally
Participant

Vinz, Datawarehouse time! Slightly off topic, but;

Example: You could now use one new user for online requests (SELECT) only.
If you limit this user, the database will always be able to store new data.

Two databases, preferably on different servers, one – the OLTP system (datawarehousing speak: on-line transactional processing) database is where the monitors send their data. Not normally queried.

Second database is an OLAP (on-line analytical processing) db. Is used for reads/queries. Can be kept near-real time with the OLTP db through clever data shuffling ETL processes.

Disadvantage is you double your data, bonus is warehouse can be denormalised for speed, can be a history too – if need be, can truncate OLTP tables and still have all data from all time in OLAP warehouse. Also solves problem of read/write contention or query deadlock.

Sounds like overkill in a project so ‘small’ but it’s growing very quickly and soon we’ll have to consider technologies like this, I think.
Author

Posts

Viewing 12 posts - 1 through 12 (of 12 total)

You must be logged in to reply to this topic.

Security: invalid data injection