Project

General

Profile

Security

Added by NdK over 1 year ago

Hello all.

Some time ago I've had an interesting exchange of mails with JCW regarding this often understimated aspect. Maybe I'm just paranoid by having thought too long about my OpenAlarm project, but recent news about ransomware that could freeze your car till you pay the ransom makes me think maybe I'm not paranoid enough :)

Apparently, there's no harm in having sensor nodes broadcast plaintext data, right?
Wrong: a nosy neighbour could easily get too much info about your life (remember how much data can be extracted from just a single current sensor on the mains line?) or, way worse, a burglar could wait till all PIR sensors are quiet (so he's sure you went to bed) to start "working" on the front door (and start selectively jamming just those nodes when he's done)...

That gets way worse if there are actuator nodes: a simple relay driver that turns on the electric coffee machine when you're not at home could start a fire... or at least give you a stroke when the next electricity bill arrives :) It already happened that a Z-wave door lock have been found susceptible to a simple replay attack!

The problem is quite complex, expecially if you don't want to lose the broadcast capability. And becomes way harder if you want to defend against an attacker that could steal and decap a node, especially if you plan to avoid relying on a single management node (to avoid SPOF).

My ideas so far are:
1) at initialization, nodes receive (securely[0]) a "base ID" and an "update key" from a coordinator node (that can even go offline after nodes are initialized)
2) every time-quantum (a minute or some other fixed interval) every node uses a Fisher-Yates shuffle [1] to determine his own "next ID" by using a PRNG seeded by the update key
3) every node must transmit at least once per period (that can be different from time-quantum -- say once a day) to avoid being marked 'down', but when doing so it must use the correct ID
4) in the sent packet there must be space for encrypted payload and for authentication, and that space must be filled by random data if not used

What do you think?

[0] being once-only, even a 14-seconds curve25519 ECDH could be acceptable (see https://rweather.github.io/arduinolibs/crypto.html )
[1] https://en.wikipedia.org/wiki/Fisher%E2%80%93Yates_shuffle


Replies (10)

RE: Security - Added by jcw over 1 year ago

a Z-wave door lock have been found susceptible to a simple replay attack

I'm surprised that a door lock vendor has the gall to ignore this well-known approach.

All the cheap one-way RF remotes I have are equally insecure. The FS20 system advertises with "over 24 million combinations!" - which is probably intended to make people think that it must be pretty secure...

This is a good discussion to be having, IMO. But we do need to keep it all in perspective - the baseline to compare against I think, is someone standing / camping outside and watching. A lot of what happens is observable, one way or another. Even without us geeks broadcasting stuff.

The good news is perhaps that actuation often involves powered nodes, so these can throw more computing power at improving security.

RE: Security - Added by NdK about 1 year ago

jcw wrote:

a Z-wave door lock have been found susceptible to a simple replay attack
I'm surprised that a door lock vendor has the gall to ignore this well-known approach.

They probably thought that simply encrypting was secure enough... :(
Not that non-electronic locks are better... I recently had a look at Kaba cylinders. The seller said they're secure, but I found on Youtube a video where one gets opened in 20 seconds creating a reusable key in the process! :(

All the cheap one-way RF remotes I have are equally insecure. The FS20 system advertises with "over 24 million combinations!" - which is probably intended to make people think that it must be pretty secure...

Well, it all depends on the scenario: you will have an hard time trying to clone your broken remote...

This is a good discussion to be having, IMO. But we do need to keep it all in perspective - the baseline to compare against I think, is someone standing / camping outside and watching. A lot of what happens is observable, one way or another. Even without us geeks broadcasting stuff.

Yep. But broadcasting data on a cloud server allows everyone in the world to "camp".

The good news is perhaps that actuation often involves powered nodes, so these can throw more computing power at improving security.

With some notable exceptions. But good crypto does not necessarily add too much to the overall budget, if well thought out.

RE: Security - Added by jcw about 1 year ago

Would a challenge-response structure be secure, with AES using a shared key? IOW, the remote sends say its 24-bit systick counter value over AES as challenge, and the host ACKs with a pre-agreed response value based on that? With the remote accepting anything based on the last N challenge values (unless already used), to deal with lost ACKs? Needs key sharing once when pairing, but after that, replay attacks become impossible?

RE: Security - Added by NdK about 1 year ago

That's the "usual" method, but that's orthogonal to dynamic node pseudonymization, that aims to avoid giving useful metatada to an attacker.

The con of challenge-response is that it requires two messages.
In one of the schemes I thought, to reduce the overhead the "master" sent such systick counter at the start of every "frame", then the nodes transmitted in their allocated timeslot (no need for arbitration). It can be dangerous if that message is not authenticated: an attacker could jam that counter and set a future date, obtaining the future correct answer from all the nodes. That could even lead to a DoS if the nodes then refuse answering to "past" systicks.
On the other hand, it's "easy" to sign a message with HMAC, since the master and every node already share a secret. Too bad, a node captured by the attacker would reveal the signing key.

To avoid that scenario, the scheme gets a bit more complex:
- every node must have a 'node key' and an 'auth key' (plus, possibly, multiple group keys), initialized securely together with shuffle secret
- the master, once per period (see point 3 of the original message), sends to every node a message (encrypted to that node's key) "from systick X update nodekey/authkey/groupNkey/shufflesecret to Z"
- if a node doesn't receive that update, the next period it won't have a valid key and will be kicked from the network (triggering a warning)

The best auth could be obtained by AES-GCM

RE: Security - Added by NdK about 1 year ago

Seems even "big players" are starting to consider security as a key point for IoT devices.
http://www.atmel.com/Microsite/security/overview.aspx

RE: Security - Added by Mars about 1 year ago

Yep, nice from Atmel, but if you click on all the "read more" links, you get the crypto chip in ALL cases!

In other words: they just want to sell you their crypto chip!

RE: Security - Added by NdK about 1 year ago

That's for sure.
It's the same for every manufacturer.
The best part is that they're starting to think about security in IoT devices.
The worst part is that Atmel's security chips' datasheets are available only under NDA, preventing development of open source projects.

RE: Security - Added by tochinet about 1 year ago

Is AES reasonable for an AVR328 ? I'm not concerned about execution time, but the RAM is pretty limited. Could part of the stash in 28J60 be (re-)used for holding the state ?
Can HTTPS: be even envisioned ? The management of certificates is even more memory-eating. Can this mean that only Cortex-grade silicon (or ESP8266) could be used in a secure IoT ?

RE: Security - Added by jcw about 1 year ago

My 2¢: it can be done, just like an Ethernet TCP/IP stack can be made to fit - but I now think these efforts are misguided (unless your whole point is to prove it).

With a 32-bit architecture and more memory most limitations simply aren't there (some STM32's even have built-in AES & SHA hardware support).

RE: Security - Added by NdK about 1 year ago

There are quite a lot of crypto algorithms already implemented, but if you have a look at the public key timings, you can easily see it's useless (at least for HTTPS).
Probably you can do RSA2048, but every op takes minutes at 100% power. Even a fast Curve25519 takes 7 seconds (vs ~250ms on ESP8266).
AES fits well and can "easily" be used (but ChaCha could be a better choiche: twice the speed, twice the keysize, better side-channel protection).

Said that, you can reduce the PK use to a minimum (say once a day, or once a week, depending on your attack scenario) just to renew key material, using symmetric crypto to encrypt and authenticate your data. That requires great attention to the details since it's way too easy to use good crypto to setup a broken system.

    (1-10/10)